Selective #include files

I am writing DXL code that has to be common accross versions of DOORS, secifically 9.3 and 9.5. I have an IBM encripted file that is different between versions and so must test for the client version and include the approriate file.

I have tried to test for the version and if 9.3 #include file 1 else include file 2, but it is not possible to have an #include inside a loop. Is it possible to use a calculated string with the include or is there another way of achieving this for example:

if (clientVersion == "9.3") includeString = file1 else includeString = file2

#include <includeString>


Chris Palmer - Tue Jun 18 08:01:03 EDT 2013

Re: Selective #include files
Johnny_P - Tue Jun 18 08:24:52 EDT 2013

Hi Chris,

the following syntax works for me:

int iIncludeFile = 2

if (iIncludeFile == 1)
{
    eval_("#include <c:/temp/includeFile_1.dxl>")
}
elseif (iIncludeFile == 2)
{
    eval_("#include <c:/temp/includeFile_2.dxl>")
}

I can select the included file by changing the value of iIncludeFile.

 

Regards

Johnny

 

edit:

I just read about the "eval_" command. Apparently you can not pass any values to the included file, so this probably won't work for you... (see eval_ Command)

Re: Selective #include files
Chris Palmer - Tue Jun 18 08:50:09 EDT 2013

Johnny_P - Tue Jun 18 08:24:52 EDT 2013

Hi Chris,

the following syntax works for me:

int iIncludeFile = 2

if (iIncludeFile == 1)
{
    eval_("#include <c:/temp/includeFile_1.dxl>")
}
elseif (iIncludeFile == 2)
{
    eval_("#include <c:/temp/includeFile_2.dxl>")
}

I can select the included file by changing the value of iIncludeFile.

 

Regards

Johnny

 

edit:

I just read about the "eval_" command. Apparently you can not pass any values to the included file, so this probably won't work for you... (see eval_ Command)

I'm not psassing any values but the file is encripted, I had tried this and can't get it to work in this instance. I will keep working on it otherwise I have 2000 installs to do over a weekend!

Re: Selective #include files
BillTidy - Tue Jun 18 10:50:36 EDT 2013

Chris Palmer - Tue Jun 18 08:50:09 EDT 2013

I'm not psassing any values but the file is encripted, I had tried this and can't get it to work in this instance. I will keep working on it otherwise I have 2000 installs to do over a weekend!

You're getting the version with the command doorsVersion? e.g.:  string dmv = doorsVersion

You can then get a substring of this (doorsVersion will give you something like 9.3.0.4 or 9.5.0.1) so you get the version part you are interested in, like 9.3 or 9.5 and then use this to select the appropriate include file.

You just use this as input to Johnny_P's suggested code. Eg.

string dmv = doorsVersion

if ( dmv[0:2] == "9.3" ) {
 eval_("#include <yourincludefilefor93>")
} else if ( dmv[0:2] == "9.5" ) {
eval_("#include <yourincludefilefor95>")
} else {
  // Incompatible version and do nothing
}

 

 

PS: If you're getting an error - which error?

 

 

Re: Selective #include files
Chris Palmer - Tue Jun 18 11:09:10 EDT 2013

BillTidy - Tue Jun 18 10:50:36 EDT 2013

You're getting the version with the command doorsVersion? e.g.:  string dmv = doorsVersion

You can then get a substring of this (doorsVersion will give you something like 9.3.0.4 or 9.5.0.1) so you get the version part you are interested in, like 9.3 or 9.5 and then use this to select the appropriate include file.

You just use this as input to Johnny_P's suggested code. Eg.

string dmv = doorsVersion

if ( dmv[0:2] == "9.3" ) {
 eval_("#include <yourincludefilefor93>")
} else if ( dmv[0:2] == "9.5" ) {
eval_("#include <yourincludefilefor95>")
} else {
  // Incompatible version and do nothing
}

 

 

PS: If you're getting an error - which error?

 

 

no problem geting the version etc, the problem only occurs when putting the #include inside a conditional statement as the # calls are preprocessed and the definitions within the include file don't get processed until after compiling. This gives the error of variables not being defined as the include file has not been included at this point.

I think I will need to look in to passing in a value and use it for a #if statement although not sure if this will work.

Re: Selective #include files
BillTidy - Tue Jun 18 13:51:51 EDT 2013

Chris Palmer - Tue Jun 18 11:09:10 EDT 2013

no problem geting the version etc, the problem only occurs when putting the #include inside a conditional statement as the # calls are preprocessed and the definitions within the include file don't get processed until after compiling. This gives the error of variables not being defined as the include file has not been included at this point.

I think I will need to look in to passing in a value and use it for a #if statement although not sure if this will work.

Just out of interest . Which dxl is it that is different between 9.3 and 9.5?

Maybe there is a different way to solve the problem if we knew the functions you were using.

Re: Selective #include files
llandale - Tue Jun 18 14:50:01 EDT 2013

I don't encrypt, but I do not recall there being an encryption difference between v93 and v95.  IIRC there was between v91 (Telelogic owned) and v92 (IBM owned).  Perhaps there is adifference in the word exporter, but I doubt the v93 version won't work in your v95 client.

In any event the other poster are correct; because the "include" file is first interpreted and then run.  If the #include statement was a run time thing, then the following would print "Hello" and then produce a DXL error; but what it does is just produce the DXL error

  • print "Hello\n"
  • #include <DoesNotExist.inc>

Now if the #include file was written to work on the "current" module, you CAN do something like this; passing the "current" module into "eval_".

  • string NameFull_InMain = fullName(current Module)   // this variable is in you main code
  • string DxlCode = "
  •   string NameFull_InEval = " NameFull_InMain "   // this variable is in your eval_ code, DxlCode
  •   Module mod = read(NameFull_InEval, false, true)
  •   current = mod
  • #include <whatever>
  • "     // end of "string DxlCode"
  • infoBox("About to Eval....\n" DxlCode)   // this is helpful so you know what the DxlCode actually looks like.
  • eval_(DxlCode)

Anything more than that is voodoo to me and you'll need help from some of the really clever folks.

-Louie

Re: Selective #include files
Chris Palmer - Wed Jun 19 02:51:19 EDT 2013

BillTidy - Tue Jun 18 13:51:51 EDT 2013

Just out of interest . Which dxl is it that is different between 9.3 and 9.5?

Maybe there is a different way to solve the problem if we knew the functions you were using.

Hi BillTidy,

The difference is in some OSLC put an get calls where IBM decided to change the name of their function calls between 9.3 and 9.4. An interface script that was written by them had to change and as it was developed by IBM services they encripted it. This script is what I have to include as a #include file.

Re: Selective #include files
sekrbo - Wed Jun 19 06:15:16 EDT 2013

llandale - Tue Jun 18 14:50:01 EDT 2013

I don't encrypt, but I do not recall there being an encryption difference between v93 and v95.  IIRC there was between v91 (Telelogic owned) and v92 (IBM owned).  Perhaps there is adifference in the word exporter, but I doubt the v93 version won't work in your v95 client.

In any event the other poster are correct; because the "include" file is first interpreted and then run.  If the #include statement was a run time thing, then the following would print "Hello" and then produce a DXL error; but what it does is just produce the DXL error

  • print "Hello\n"
  • #include <DoesNotExist.inc>

Now if the #include file was written to work on the "current" module, you CAN do something like this; passing the "current" module into "eval_".

  • string NameFull_InMain = fullName(current Module)   // this variable is in you main code
  • string DxlCode = "
  •   string NameFull_InEval = " NameFull_InMain "   // this variable is in your eval_ code, DxlCode
  •   Module mod = read(NameFull_InEval, false, true)
  •   current = mod
  • #include <whatever>
  • "     // end of "string DxlCode"
  • infoBox("About to Eval....\n" DxlCode)   // this is helpful so you know what the DxlCode actually looks like.
  • eval_(DxlCode)

Anything more than that is voodoo to me and you'll need help from some of the really clever folks.

-Louie

Well the question as I understand it is not the encryption, but the content of the encrypted file.

I've run into that as well. I based a script on the standard comma separated import, version 9.5.0.1, which failed misserably when run on a 9.3.x installation - the functions in the standard includes had changed... Couldn't find any documentation in tghe read me files that the spreadsheet import had changed - it had! I seem to remember that it had to do with the Advanced button at the bottom, and that the import now looks at your local for the encoding. Which makes life a bit of a problem :) If I export from DOORS, it saves it in UTF-8 by default (does not look at locale), and when I try to import the same file, it will not work, as my local now says it should by default be in ANSI - Latin I. Nice feature - not really thought out...

/sekrbo